home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-cat-ftpsec-01.txt
< prev
next >
Wrap
Text File
|
1993-04-22
|
37KB
|
870 lines
Network Working Group Internet Engineering Task Force
Internet-Draft Common Authentication Technology Working Group
Updates: RFC 959 S. J. Lunt
Bellcore
April 1993
FTP Security Extensions
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Distribution of this memo is unlimited. Please send comments to the
<ftp-wg@tgv.com> mailing list.
1. Description
This document defines extensions to the FTP specification RFC 959,
"FILE TRANSFER PROTOCOL (FTP)" (October 1985), which provide strong
authentication, integrity, and confidentiality on both the control
and data channels with the introduction of new optional commands,
replies, and file transfer encodings.
The following new optional commands are introduced in this
specification:
AUTH (Authentication Type), ADAT (Authentication Data), MIC
(Integrity Protected Command), ENC (Privacy Protected Command),
and PROT (Data Channel Protection Level).
A new class of reply types (6yz) is also introduced for protected
replies.
Expires: October 31, 1993 [Page 1]
Internet-Draft FTP Security Extensions April 1993
None of the above commands are required to be implemented, but each
is dependent on the other (except ENC, which is optional).
Note that this specification is compatible with RFC 959.
2. Motivation
The File Transfer Protocol (FTP) currently defined in RFC 959 and in
place on the Internet uses usernames and passwords passed in
cleartext to authenticate clients to servers (via the USER and PASS
commands). Except for services such as 'anonymous' FTP archives,
this represents a security risk whereby passwords can be stolen
through monitoring of local and wide-area networks. This either aids
potential attackers through password exposure and/or limits
accessibility of files to remote users who can or will not accept the
inherent security risk.
Aside from the problem of authenticating users in a secure manner,
there is also the problem of protecting sensitive data and/or
verifying its integrity. An attacker may be able to access valuable
or sensitive data merely by monitoring a network, or through active
means may be able to delete or modify the data being transferred so
as to corrupt its integrity. An active attacker may also initiate
spurious file transfers to and from a site of the attacker's choice,
and may invoke other commands on the server. FTP does not currently
have any provision for the encryption or verification of the
authenticity of commands, replies, or transferred data. Note that
these security services have value even to anonymous file access.
Current practice for sending files securely is generally either:
1. via FTP of files pre-encrypted under keys which are manually
distributed,
2. via electronic mail containing an encoding of a file encrypted
under keys which are manually distributed,
3. via a PEM message, or
4. via the rcp command enhanced to use Kerberos.
None of these means could be considered even a de facto standard, and
none are truly interactive. A need exists to securely transfer files
using FTP in a secure manner which is supported within the FTP
protocol in a consistent manner and which takes advantage of existing
security infrastructure and technology. Extensions are necessary to
the FTP specification if these security services are to be introduced
into the protocol in an interoperable way.
Expires: October 31, 1993 [Page 2]
Internet-Draft FTP Security Extensions April 1993
Although the FTP control connection follows the Telnet protocol, and
Telnet has defined an authentication and encryption option [5], RFC
1123 [4] explicitly forbids the use of Telnet option negotiation over
the control connection (other than Synch and IP). Also, the Telnet
authentication and encryption option does not provide for integrity
protection only (without confidentiality), and does not address the
protection of the data channel.
3. New FTP Commands
The following commands are optional, but dependent on each other.
They are extensions to the FTP Access Control Commands.
AUTHENTICATION TYPE (AUTH)
The argument field is a Telnet string identifying a supported
authentication mechanism. The command represents a request to
perform an authentication protocol exchange based on an
authentication mechanism identified by the argument. Currently,
only KERBEROS_V4 and GSSAPI are defined.
If the server accepts an authentication type with reply code 334,
then the client must next initiate an authentication exchange (via
the ADAT command) based on that authentication type. The goal of
the authentication exchange is to strongly authenticate the user
to the server, and to establish a security context [3] under which
protection of the control and data channels may be performed.
If the server replies with a 234 code, then the authentication
type is accepted, and no ADAT commands are required. This is
useful to indicate to the server that the password to be sent in a
subsequent PASS command is to be interpreted differently than
normal, as in the case of smart cards or other non-disclosing
password systems. Challenge information intended for human
interpretation may be contained in the reply. Such information
may also be conveyed in the text of the reply to the USER command.
If the server rejects a type (reply code 504), or any ADAT command
fails, then the client may try another authentication type by
issuing another AUTH command, or may continue by sending USER and
PASS commands. Thus, the client should request authentication
types in decreasing order of preference (i.e., strength). The
server will reject (with a 503 reply code) any AUTH or ADAT
commands sent after an authentication protocol successfully
completes.
The client should not require the server to support the AUTH
command or any particular authentication type. If either the
server does not support the AUTH command (reply code 500), or the
client and server cannot agree on an authentication type, or no
Expires: October 31, 1993 [Page 3]
Internet-Draft FTP Security Extensions April 1993
authentication exchange succeeds, then the default USER and PASS
commands must be performed.
The AUTH command will normally be the first command transmitted by
the user after the control connections are made, generally before
the USER command. However, the AUTH command may cause the control
connection to be closed by servers which require the USER command
to be the first command transmitted by the user after the control
connection is made.
Some servers will require that authentication be performed before
certain commands (including USER) will be accepted. In this case,
a 530 reply will be sent indicating that an authentication
exchange is required.
Some authentication protocols may require prior knowledge of the
remote user name (e.g., some challenge/response systems). In this
case, the USER command may be sent in advance of the AUTH command.
AUTHENTICATION DATA (ADAT)
The argument field is a Telnet string representing a base 64
encoded authentication data (see the definition of the MIC command
for a description of base 64 encoding). The data is specific to
the authentication protocol specified by a previous AUTH command.
The ADAT command, and the associated replies, allow the client and
server to conduct an arbitrary authentication protocol. The
client will send authentication data to the server via the ADAT
command, and the server will send authentication back to the
client by including "ADAT=string" in the reply, where string is
also a Telnet string representing base 64 encoded authentication
data. The server will reply 501 if the string could not be base
64 decoded.
If the server sends a 535 reply, then the authentication data
could not be successfully processed, and the client has not been
authenticated. The client may either try another authentication
type by sending another AUTH command, or may send USER and PASS
commands. The server will reply 503 if no AUTH command was
previously accepted.
If the server sends a 335 reply, then the authentication data was
successfully processed, but more authentication data is necessary
to complete the authentication process. In this case, the server
must include encoded authentication data in the reply. The client
must process this returned data and then issue another ADAT
command.
If the server sends a 235 reply, optionally including encoded
Expires: October 31, 1993 [Page 4]
Internet-Draft FTP Security Extensions April 1993
authentication data, then the server considers the client
authenticated. The client must process any authentication data
present in the reply.
Appendix I defines the actual protocol for KERBEROS_V4. Appendix
II defines the actual protocol for GSSAPI.
If an authentication exchange succeeds, then the client's identity
has been authenticated but not yet authorized. The client must
next invoke the USER command to identify to the server the account
(file system) for which access is requested. If the USER command
results in a 231 reply, then the client is authorized, and no
password is required. However, the client must then send the PASS
command to actually log the user in (the actual password is
ignored and should be a dummy value). If the USER command results
in a 333 reply, then the user was not authorized without a
password, and a password must be sent with the PASS command. In
this case, it is recommended that the PASS command be ENC
protected. Additional USER or PASS commands may be sent after
success of an ADAT command.
Once the client is successfully authenticated via AUTH and ADAT
commands, the rest of the data over the control channel (commands
and replies) must be protected, either with integrity (by a
cryptographic checksum) via the MIC command, or with
confidentiality (by encryption) via the ENC command. (Also see
Section 4 on protected replies.) These two commands may be
arbitrarily intermixed. It is up to the client to decide which of
MIC and ENC commands to use, and it is up to the server when to
accept either. The server will return a 502 reply to any other
command. The server will return a 500 reply to a MIC or ENC
command if no ADAT command succeeded.
Commands sent via the Telnet out-of-band signal must also be
protected. That is, if the client sends the Telnet "Interrupt
Process" (IP) signal followed by the Telnet "Synch" signal, then
the command sent to the server immediately afterwards must also
protected.
A requirement of all specifications for authentication exchanges
based on new authentication types is that they convey to the
caller whether encryption is supported on the resultant security
context, since it is not a requirement that the ENC command, 632
protected replies, or the Private protection level be supported.
It is also strongly suggested that per message protection services
supported by each mechanism perform message replay and out-of-
sequence detection, since no provision for these services is
explicitly made within this specification.
Since no explicit provision is made in this specification for the
Expires: October 31, 1993 [Page 5]
Internet-Draft FTP Security Extensions April 1993
negotiation of alternate mechanisms for performing per message
protection services, implementors should instead utilize the token
exchange for this purpose.
INTEGRITY PROTECTED COMMAND (MIC)
The argument field is a Telnet string consisting of a base 64
encoded "safe" message produced by an authentication mechanism
specific message integrity procedure. The server will decode the
received string, verify its integrity via the authentication
mechanism specific message integrity procedure, and upon success,
interpret the resultant string as an FTP command. The user-
process need not include the Telnet end-of-line code within the
encoded command.
Base 64 encoding is the same as the Printable Encoding described
in Section 4.3.2.4 of [2] and is defined as follows.
Proceeding from left to right, the bit string resulting from the
mechanism specific protection routine is encoded into characters
which are universally representable at all sites, though not
necessarily with the same bit patterns (e.g., although the
character "E" is represented in an ASCII-based system as
hexadecimal 45 and as hexadecimal C5 in an EBCDIC-based system,
the local significance of the two representations is equivalent).
A 64-character subset of International Alphabet IA5 is used,
enabling 6 bits to be represented per printable character. (The
proposed subset of characters is represented identically in IA5
and ASCII.) The character "=" signifies a special processing
function used for padding within the printable encoding procedure.
The encoding process represents 24-bit groups of input bits as
output strings of 4 encoded characters. Proceeding from left to
right across a 24-bit input group extracted from the output of
step 3, each 6-bit group is used as an index into an array of 64
printable characters, namely "[A-Z][a-z][0-9]+/". The character
referenced by the index is placed in the output string. These
characters are selected so as to be universally representable, and
the set excludes characters with particular significance to Telnet
(e.g., "<CR>", "<LF>", IAC).
Special processing is performed if fewer than 24 bits are
available in an input group at the end of a message. A full
encoding quantum is always completed at the end of a message.
When fewer than 24 input bits are available in an input group,
zero bits are added (on the right) to form an integral number of
6-bit groups. Output character positions which are not required
to represent actual input data are set to the character "=".
Expires: October 31, 1993 [Page 6]
Internet-Draft FTP Security Extensions April 1993
Since all canonically encoded output is an integral number of
octets, only the following cases can arise: (1) the final quantum
of encoding input is an integral multiple of 24 bits; here, the
final unit of encoded output will be an integral multiple of 4
characters with no "=" padding, (2) the final quantum of encoding
input is exactly 8 bits; here, the final unit of encoded output
will be two characters followed by two "=" padding characters, or
(3) the final quantum of encoding input is exactly 16 bits; here,
the final unit of encoded output will be three characters followed
by one "=" padding character.
Implementors should keep in mind that the base 64 encodings in
ADAT, MIC, and ENC commands, and in 631 and 632 replies, may be
arbitrarily long. Thus, the entire line must be read before it
can be processed. Several successive reads on the control channel
may be necessary. It is not appropriate to for a server to reject
a command containing a base 64 encoding simply because it is too
long (assuming that the decoding is otherwise well formed in the
context in which it was sent).
The server will return a 501 reply if the argument could not be
properly base 64 decoded.
The server will return a 535 reply to any MIC command which fails
checksum, replay, sequencing, or other applicable security checks.
There are no other direct replies from MIC or ENC commands; the
resultant FTP command will generate its own replies.
In environments where the native character set is not ASCII, the
client must translate the encapsulated command to ASCII before
passing it to the protection routine, and the server must
translate the encapsulated command from ASCII after passing the
token to the protection routine.
PRIVACY PROTECTED COMMAND (ENC)
The argument field is a Telnet string consisting of a base 64
encoded "private" message produced by an authentication mechanism
specific message confidentiality procedure. The server will
decode the received string, verify its integrity and
confidentiality via the authentication mechanism specific message
confidentiality procedure, and upon success, interpret the
resultant string as an FTP command.
It is strongly recommended that PASS commands be sent under ENC
protection, when possible.
The server will return a 501 reply if the argument could not be
Expires: October 31, 1993 [Page 7]
Internet-Draft FTP Security Extensions April 1993
properly base 64 decoded.
The server will return a 535 reply to any ENC command which cannot
be properly decrypted, or fails checksum, replay, sequencing, or
other applicable security checks.
The server will return a 402 reply if it does not support the ENC
command. In this case, the client should retry the enclosed
command again under MIC protection.
DATA CHANNEL PROTECTION LEVEL (PROT)
The argument is a single Telnet character code specifying the data
channel protection level. The PROT command will be rejected and
the server will reply 504 if no previous ADAT command succeeded,
or the specified protection level is not supported. Upon success,
a 200 reply will be sent by the server, indicating that the new
protection level is now in effect.
The following codes are assigned for protection levels:
C - Clear
S - Safe
P - Private
The default protection level is Safe, unless no ADAT command
succeeded, in which case the default protection level is Clear.
Thus, when an ADAT command succeeds, the protection level on the
client and server changes to Safe without the passing of a PROT
command. The Safe protection level is required to be implemented
by all authentication types, but the Private protection level is
optional.
When using the Safe protection level, all data sent over the data
channel is to be integrity protected by cryptographic checksum.
When using the Private protection level, all data sent over the
data channel is to be privacy protected by encryption. The sender
will apply protection services after all data transformations
associated with the current representation type, file structure,
and transfer mode have been performed. The data sent over the
data channel is, for the purposes of data protection, to be
treated as a byte stream. An authentication mechanism specific
data protection procedure will be employed by the sender to
protect this byte stream. The procedure should process a buffer
of bytes at a time, and send the result as a stream of bytes,
prepending each transferred buffer with a four byte length field
(most significant byte first). A minimal implementation must be
Expires: October 31, 1993 [Page 8]
Internet-Draft FTP Security Extensions April 1993
able to handle a buffer length of at least 65,536 bytes. The
receiver will read the four byte length field, and then read that
number of bytes of protected data, passing the buffer to an
authentication mechanism specific data protection procedure.
Further buffers will be similarly read and processed until all
bytes are sent. Any transformations associated with the current
representation type, file structure, and transfer mode would then
be performed on the resultant data. When using block transfer
mode, the sender's (cleartext) buffer size should be equal to the
block size.
Under the Clear protection level (i.e., as currently defined in
RFC 959), and when in stream mode, the sender indicates end of
file by closing the data connection. This is inherently
unreliable, since the receiver cannot determine whether the
connection was closed prematurely. Transferring files under the
Safe or Private protection level allows the sender to convey a
positive indication of end of file by sending a protected buffer
which contains zero bytes of cleartext data. Upon receipt of such
a zero length cleartext buffer, the recipient should close the
data connection (without further reading from the connection) and
consider the file transfer complete. If the connection is closed
before such a buffer is received, then the file transfer should be
aborted, and the user should be alerted. If the server was the
recipient, then it should send a 535 reply in this case.
If any data protection services fail at any time during data
transfer at the server end, the server will send a 535 reply.
4. New FTP Replies
All replies after a successful ADAT command must be protected. A new
reply type is introduced for this purpose, indicated by a sixth value
for the first digit of the reply code:
6yz Protected reply
The text of this reply is to be decoded and interpreted as an FTP
reply (if such decoding is successful). If the reply code is 631,
then the text of the reply is integrity protected in the same
manner as MIC commands. If the reply code is 632, then the text
of the reply is privacy protected in the same manner as ENC
commands. All replies must be protected once an ADAT command
succeeds. The server may send a protected reply only if a
previous ADAT command succeeded. The security policy of the
server will dictate when 631 or 632 replies are to be used. As a
general rule, the server should send a 631 reply to a MIC command,
and a 632 reply to an ENC command.
Expires: October 31, 1993 [Page 9]
Internet-Draft FTP Security Extensions April 1993
The server must not send 632 replies if the client does not
support encryption (this should be indicated by the security
context). If, upon context establishment, it is not known whether
the client supports encryption, then the server must only send a
632 reply in response to an ENC command.
Multi-line replies are handled as follows. If the server sends a
protected reply in which the decoded reply has a hyphen ("-")
immediately following the reply code, then the server will send
the rest of the lines of text of the multi-line reply each
protected and base 64 encoded as was the first line, and each
followed by the Telnet end-of-line code. The last line of the
multi-line reply will be that line which when decoded by the
receiver begins with the initial reply code followed by a space.
Note that it is the format of the decoded reply, and not the
enclosing protected reply, that indicates a multi-line reply. A
hyphen immediately following a 6yz reply code should be ignored.
The server need not include the Telnet end-of-line code within the
encoded reply.
If the server for some reason cannot encode the reply, then the
unprotected reply will be sent instead. However, the client
should ignore the reply code of any cleartext reply sent after the
success of an ADAT command, and instead simply display the text of
the reply to the user.
5. Command Summary
The following is a summary of the commands described above:
AUTH <SP> <auth-type> <CRLF>
ADAT <SP> <base64string> <CRLF>
MIC <SP> <base64string> <CRLF>
ENC <SP> <base64string> <CRLF>
PROT <SP> <protection-level> <CRLF>
The syntax of the above argument fields (using BNF notation where
applicable) is:
<auth-type> ::= <string>
<string> ::= <char> | <char><string>
<char> ::= any of the 128 ASCII characters except <CR> and <LF>
<protection-level> ::= C | S | P
<base64string> ::= <quads> | <quads><terminal>
<quads> ::= <quad> | <quad><quads>
<quad> ::= <base64char><base64char><base64char><base64char>
<base64char> ::= ASCII A through Z
| ASCII a through z
| ASCII 0 through 9
Expires: October 31, 1993 [Page 10]
Internet-Draft FTP Security Extensions April 1993
| ASCII +
| ASCII /
<terminal> ::= <base64char><terminal1><pad><pad>
| <base64char><base64char><terminal2><pad>
<terminal1> ::= ASCII A through D
<terminal2> ::= ASCII A through P
<pad> ::= ASCII =
The following lists the various reply codes for each new command:
AUTH
234
334
500, 501, 503, 504, 421
ADAT
235
335
500, 501, 503, 535, 421
MIC
500, 501, 535, 421
ENC
402
500, 501, 535, 421
PROT
200
500, 501, 504, 421, 530
The following are additional reply codes for existing commands (502
is the only reply for all commands except ENC and MIC once an ADAT
command succeeds):
USER
231
333
STOR
535
STOU
535
RETR
535
LIST
535
NLST
535
APPE
535
The following is the syntax for protected replies:
Expires: October 31, 1993 [Page 11]
Internet-Draft FTP Security Extensions April 1993
<code> <SP> <base64string> <CRLF>
<code> ::= 631 | 632
Lines of the following form may follow in the case of a multi-line
protected reply:
<base64string> <CRLF>
6. References
[1] Reynolds, Joyce, and Postel, Jon, "File Transfer Protocol (FTP)",
RFC 959, ISI, October 1985.
[2] Linn, John, "Privacy Enhancement for Internet Electronic Mail:
Part I: Message Encryption and Authentication Procedures", RFC
1421, February 1993.
[3] Linn, John, "Generic Security Service API (GSSAPI)", Internet
Draft, November 1992.
[4] Braden, R., "Requirements for Internet Hosts -- Application and
Support", RFC 1123, October 1989.
[5] Borman, D., "Telnet Authentication and Encryption Option",
Internet Draft, Cray Research, Inc, April 1993.
Security Considerations
Third party file transfers cannot be secured using these extensions,
since a security context cannot be established between two servers
using these facilities (no control connection exists between server
over which to pass ADAT tokens). Further work in this area is
deferred.
APPENDIX I: SPECIFICATION UNDER KERBEROS VERSION 4
The authentication type (for the AUTH command) associated with
Kerberos Version 4 is KERBEROS_V4. If the server supports
KERBEROS_V4, it will respond with a 334 reply code indicating that an
ADAT command is expected next.
The client should retrieve a ticket for the Kerberos principal
"ftp.hostname@realm" by calling krb_mk_req(3) with a principal name
of "ftp", an instance equal to the canonical host name of the server
with all letters in lower case (as returned by krb_get_phost(3)), the
server's realm name (as returned by krb_realmofhost(3)), and an
arbitrary checksum. The ticket must then be base 64 encoded and sent
as the argument to an ADAT command.
The server must base 64 decode the argument to the ADAT command and
Expires: October 31, 1993 [Page 12]
Internet-Draft FTP Security Extensions April 1993
pass the result to krb_rd_req(3). The server must add one to the
checksum from the authenticator and sign it using krb_mk_safe(3),
then base 64 encode the result. Upon success, the server must reply
to the client with a 235 code and include "ADAT=base64string" in the
text of the reply. Upon failure, the server will reply 535.
Upon receipt of the 235 reply from the server, the client must parse
the text of the reply for the base 64 encoded data, decode it, and
pass the result to krb_rd_safe(3). The client should consider the
server authenticated if the resultant checksum is equal to one plus
the value previously sent.
The procedure associated with integrity protected MIC commands,
replies, and Safe file transfers is:
krb_mk_safe(3) for the sender
krb_rd_safe(3) for the receiver
The procedure associated with privacy protected ENC commands,
replies, and Private file transfers is:
krb_mk_priv(3) for the sender
krb_rd_priv(3) for the receiver
Note that this specification for KERBEROS_V4 contains no provision
for negotiating alternate means for integrity and confidentiality
routines. Note also that the ADAT exchange does not convey whether
the peer supports confidentiality services.
APPENDIX II: SPECIFICATION UNDER THE GSSAPI
The authentication type (for the AUTH command) associated with all
mechanisms employing the GSSAPI is GSSAPI. If the server supports an
authentication mechanism employing the GSSAPI, it will respond with a
334 reply code indicating that an ADAT command is expected next.
The client should begin the authentication exchange by calling
GSS_Init_Sec_Context, passing in NULL for claimant_cred_handle to get
the default credentials for the user (this is to avoid dependencies
on names for particular mechanisms), 0 for input_context_handle
(initially), NULL for mech_type (indicating "use default mechanism
type"), and a targ_name equal to output_name from GSS_Import_Name
called with input_name_type of NULL and input_name_string of
"SERVICE:ftp@hostname" where "hostname" is the fully qualified host
name of the server with all letters in lower case. The output_token
must then be base 64 encoded and sent to the server as the argument
to an ADAT command. If GSS_Init_Sec_Context returns
GSS_CONTINUE_NEEDED, then the client should expect a token to be
returned in the reply to the ADAT command. This token should
subsequently be passed to another call to GSS_Init_Sec_Context. In
Expires: October 31, 1993 [Page 13]
Internet-Draft FTP Security Extensions April 1993
this case, if GSS_Init_Sec_Context returns no output_token, then the
reply code from the server for the previous ADAT command should have
been 235. If GSS_Init_Sec_Context returns GSS_COMPLETE, then no
further tokens should be expected from the server, and the client
should consider the server authenticated.
The server must base 64 decode the argument to the ADAT command and
pass the resultant token to GSS_Accept_Sec_Context as input_token,
setting acceptor_cred_handle to NULL (for "use default credentials"),
and 0 for input_context_handle (initially). If an output_token is
returned, it should be base 64 encoded and returned to the client by
including "ADAT=base64string" in the text of the reply. If
GSS_Accept_Sec_Context returns GSS_COMPLETE, the reply code should be
235, and the server should consider the client authenticated. If
GSS_Accept_Sec_Context returns GSS_CONTINUE_NEEDED, the reply code
should be 335. Otherwise, the reply code should be 535, and the text
of the reply should contain a descriptive error message.
The procedure associated with integrity protected MIC commands,
replies, and Safe file transfers is:
GSS_Safe for the sender
GSS_Verify for the receiver
The procedure associated with privacy protected ENC commands,
replies, and Private file transfers is:
GSS_Seal for the sender
GSS_Unseal for the receiver
Both the client and server should inspect the value of conf_avail to
determine whether the peer supports confidentiality services.
Author's Address:
Steven J. Lunt
Bellcore
RRC-1L213
444 Hoes Lane
Piscataway, NJ 08854
Phone: (908) 699-4244
EMail: lunt@bellcore.com
Mailing List: ftp-wg@tgv.com
Chair's Address:
The working group can be contacted via the current chair:
Expires: October 31, 1993 [Page 14]
Internet-Draft FTP Security Extensions April 1993
Sam Sjogren
TGV, Inc.
603 Mission St.
Santa Cruz, CA 95060
Phone: (408) 427-4366
EMail: sjogren@tgv.com
Author's Notes:
This is implemented and working for Kerberos V4 on SunOS 4.1.2 using
SunOS source for ftp and ftpd, and also the BSD Reno source for ftp
and ftpd.
YET TO BE DONE:
1. Determine a suitably general targ_name for GSSAPI.
2. Implementation using GSSAPI.
3. The client may fail when processing the ADAT data from a 235
reply, in which case the server thinks things are OK, but the
client thinks otherwise. Unclear how to proceed at that point,
other than to drop the connection.
4. New state diagrams might need to be drawn for how the AUTH,
ADAT, USER, and PASS commands now flow.
5. It would be desirable to make use of the rcmd principal in
Kerberos V4, but there may be some environments where the ftp
server needs to run in a chroot'ed environment. Thus, the ftp
principal was specified. There should be some way to make use
of the rcmd principal if there is no ftp principal at the
server site.
Expires: October 31, 1993 [Page 15]